Goal oriented execution for LOTOS

The dynamic semantics of LOTOS are defined in terms of axioms and inference rules which generate, from a given behaviour expression, the next possible actions and their resulting behaviour expressions. In this paper, we present a new type of inference rules, which are capable of generating traces of actions leading to a pre-selected action in the specification. These inference rules are guided by the static derivation path of the pre-selected action, which locates the action in the abstract syntactic tree of the current behaviour statically. This allows a considerable reduction of the search space. Such a technique often permits the analysis of divergent specifications that are generally beyond the capabilities of verification tools based on traces. Introduction LOTOS interpreters in existence today can function usually according to two main execution modes: Step-by-step execution [LOBF88, vE88, vE89, Tre89, GHHL88, HH89]: the specification is executed action by action where the set of possible next actions is determined after the execution of an action. The user plays the role of the environment and resolves non-determinism, by deciding what next action should be selected, and by providing the required value expressions. Obviously, this execution mode is tedious if one wishes to execute the specification for more than a few dozen steps. Eager execution: in this execution mode, the system attempts to go as far as possible, without user intervention, in the calculation of the behaviour tree of the specification. Values to be provided by the environment are replaced by symbolic values, or are provided by a "narrowing" algorithm [RKKL85]. An option in this execution mode is recognizing the fact that a previously encountered behaviour expression is encountered again, which means that a loop has been found [GL89, QFP88]. The output of eager evaluation can be either a symbolic behaviour tree [GL89, HH89, Ash92], or an expanded version of the specification [QFP88, Ash92]. The main problem with this execution mode is that symbolic behaviour trees grow often too quickly, although remedies have been considered, such as cutting off infeasible paths by narrowing, or reducing the size of the tree by compacting it [QFP88]. There are, of course, intermediate solutions. Smile [vEE91] enables the user to explore interactively symbolic behaviour trees. In any system, it is possible to restrict exploration to certain sub-trees by adding constraints, such as testing processes [GHHL88].